Confidential Strategic Dossier  ·  Campaign Operations

Campaign Quality GateAutomation Architecture

From chronic error exposure to structural prevention.

A three-layer automated intelligence system embedded into the existing Jira campaign pipeline, designed to eliminate the structural conditions that allow campaign errors to reach customers.

Platform Environment SFMC & SAS Marketing Automation
Team Scale 30 campaign operators
Monthly Volume 100–200 campaigns per month
Orchestration n8n + Claude Sonnet AI Agents
Ticketing System Jira Software Cloud
30%
Current post-send error rate, the baseline this architecture eliminates
Baseline State
<5%
Target error rate within 90 days of full deployment
Target State
3
Automated quality gates inserted into the existing pipeline
Prevention Layers
0
Process changes required from campaign team to activate
Team Disruption
Strategic Position

What this architecture actually solves

This is not an incremental improvement to the existing QA process. It is a structural intervention that relocates the point of error detection from after send to before build begins, eliminating the conditions that allow errors to reach the pipeline at all.

01
Root Cause Targeting

Errors are not discovered late because QA is inadequate. They originate at brief ambiguity and segment misconfiguration, upstream of where current controls operate. This architecture intervenes at origin.

02
Zero Team Behaviour Change

Every gate triggers from Jira status transitions your team already performs. There are no new tools, no new steps, no training requirements. The intelligence is embedded invisibly into the existing workflow.

03
Machine-Verified Standards

The 75-point checklist was a human judgment exercise. These gates convert that judgment into deterministic machine verification, applied consistently at every campaign, regardless of operator experience or workload pressure.

Business Context

The operational environmentthat created the problem

Understanding why a 30-person team with a 75-point checklist and dedicated QA resources still operates at a 30% error rate requires looking at the structural dynamics, not the individual performance.

The Pipeline As It Exists Today

Campaign briefs enter as Jira tickets. Builders interpret them. Builds are reviewed against a 75-point manual checklist. QA approvers validate. Campaigns send. Errors surface post-send, from customers, stakeholders, or compliance teams.

30%
Of campaigns contain errors that are discovered after send, triggering rework cycles, customer compensation events, delayed execution, and in regulated categories, compliance reporting obligations.
Why More QA Doesn't Solve It

The instinct to add more QA resource is logical but misapplied. Three structural dynamics explain why:

Errors originate upstream. Brief ambiguity and segment misconfiguration occur before QA sees the work. QA is reviewing an already-flawed build.
Checkers lack a reliable truth source. Validating against an ambiguous brief is a judgment exercise, not a verification one. Two reviewers reach different conclusions from the same input.
Volume pressure erodes scrutiny. At 100–200 campaigns per month, checkers make cognitive shortcuts under time and workload pressure, this is human, not negligent.
Error Origin Analysis Where the 30% error rate actually comes from

Based on the diagnostic conducted across this team's campaign operations, three error origin categories account for the majority of post-send failures:

Error OriginMechanismCurrent Detection PointGate That Prevents ItSeverity
Brief AmbiguityVague segment criteria, missing suppression lists, unspecified offer IDs, builder interprets incorrectlyPost-send, by stakeholder or customerGate 1, Brief ValidationHigh
Segment MisconfigurationWrong audience extracted from SFMC/SAS, wrong criteria applied, suppressions missing, count outside expected rangePost-send, when complaints arriveGate 2, Segment SanityHigh
Campaign Logic ErrorsContent ID mismatch, broken tokens, wrong send time, channel/content type conflictPost-send or during last-minute human QAGate 3, Pre-Send QAMedium
Compliance OmissionsMissing unsubscribe links, incorrect opt-in basis, regulatory flags not actionedPost-send, compliance auditGate 3, Pre-Send QAHigh
Communication GapsBriefs updated after build started, late modifications, builder/requester misalignmentMid-production or post-sendGate 1 re-trigger on re-submissionMedium

Review Operational Architecture

Walk through the current-state pipeline, bottleneck mapping, and structural diagnosis with a transformation strategist.

Schedule Diagnostic Session
Automation Architecture

Three intelligent quality gatesembedded in your Jira pipeline

Each gate is an n8n AI agent workflow triggered by a Jira status transition. The agent reads the issue context, performs its validation using connected APIs, and takes autonomous action, updating Jira, notifying the relevant team in Slack, and blocking or approving progression.

G1
Brief Validation Gate

Fires when a campaign brief is submitted. Validates all 12 required fields before any builder sees the ticket. Eliminates the root cause of misinterpretation errors.

Trigger Brief Submitted
Fields validated 12
AI model Claude Sonnet 4
Integration Jira + Slack
G2
Segment Sanity Gate

Fires when a campaign build is marked complete. Calls SFMC and SAS APIs to validate actual audience count against the expected range declared in the brief. Catches wrong-audience errors before QA.

Trigger Build Complete
Variance threshold ±20%
APIs called SFMC REST + SAS API
Integration Jira + Slack
G3
Pre-Send QA Gate

Fires after QA approval. Validates the live SFMC build against the approved brief, content IDs, personalisation tokens, send configuration, compliance elements. Last automated barrier before send.

Trigger QA Approved
Checks performed 16+
APIs called SFMC Content + Send Def
Outputs Jira + Slack + Email
How the three gates connect, Trigger → Logic → Action
Brief
Submitted
Gate 1
12-field check
✓ Pass
✕ Fail ↩
Build
Complete
Gate 2
Audience count
✓ Pass
✕ Fail ↩
QA
Approved
Gate 3
16-point QA
✓ Pass
✕ Fail ↩
Approved
to Send

Explore Deployment Feasibility

Understand the infrastructure requirements, credential setup, and estimated deployment timeline for your environment.

Request Infrastructure Audit
Gate Logic Detail

What each agent validatesand exactly how it decides

Each gate operates on a defined decision ruleset embedded in its AI agent system prompt. The logic is deterministic, specific criteria must be satisfied for a pass outcome. There is no subjective interpretation.

G1
Brief Validation Agent
Trigger: status = "Brief Submitted"

The agent reads the entire Jira issue, all fields, description, and custom brief fields. It evaluates each of the 12 required brief elements against defined acceptance criteria. A partial pass is a full fail, all 12 must satisfy the criteria before the brief is approved to build.

12 Validated Fields
Campaign Name, must be unique and descriptive, not a generic placeholder
Target Segment Criteria, must include specific, filterable conditions. "Active customers" fails; "opted-in with purchase in last 90 days" passes
Expected Audience Size, explicit min-max range required
Channel, one of: SFMC Email, SFMC SMS, SAS Campaign, Push, Direct Mail
Content / Offer Reference ID, specific template or approved offer code
Send Date and Time, exact date + time + timezone
Journey or Automation Name, matching an existing SFMC Journey or SAS Campaign
Suppression Groups, named lists required; "standard" without names fails
Control / Holdout Group, % stated or "None, [explicit reason]"
Regulatory & Compliance Flags, opt-in basis, GDPR/CCPA/SPAM Act status
Campaign Owner, named individual, not a team or role
Stakeholder Approval, approver name + approval date documented
Pass Outcome
All 12 fields validated → Ready for Build
Jira comment posted: "BRIEF VALIDATION PASSED, [timestamp]. All 12 fields validated."
Issue transitioned to Ready for Build
Slack notification to build team with campaign name and assignment prompt
Fail Outcome
Any field fails → Brief Required
Jira comment posted with field-by-field failure report, each gap identified with what was found and exactly what is required
Issue transitioned to Brief Required
Slack notification to the brief requester with gap count and instruction to correct and resubmit

Re-setting status to "Brief Submitted" after correction re-triggers Gate 1 automatically. The loop closes cleanly.

G2
Segment Sanity Agent
Trigger: status = "Build Complete"

The agent reads the approved brief's expected audience range, then makes live API calls to SFMC or SAS to retrieve the actual segment count. It compares actual vs expected and flags anomalies that would not be visible from a visual review of the build.

Validation Logic
1Read brief, extract expected audience min/max, channel, segment/DE name, suppression groups
2API call, SFMC REST API (Data Extension rowset count) or SAS Campaign API (audienceCount endpoint)
3Compare, actual count vs declared min-max range
4Suppression inference, if count significantly exceeds expected max, flags possible missing suppression
5Zero check, count of 0 is an automatic fail regardless of other conditions
Variance Threshold: ±20%
Counts within 20% of expected range pass with variance noted. Counts outside 20% trigger an investigation-required fail.
Pass Outcome
Count within range → Ready for QA
Jira comment: "SEGMENT VALIDATION PASSED, Count: [N] (Expected: min–max). Variance: X%."
Issue transitioned to Ready for QA
Slack to QA team with confirmed count
Fail Outcome
Count anomaly → Build Required
Jira comment with actual count, expected range, variance %, and likely causes (over/under by direction)
Issue transitioned to Build Required
Slack to builder: segment count anomaly, investigation required
G3
Pre-Send QA Agent
Trigger: status = "QA Approved"

The final gate. The agent retrieves the live SFMC content asset and send definition, then cross-references them against the approved brief. 16+ checks across content, audience configuration, and compliance.

Content Checks
Subject line vs brief specification
From name and address vs approved sender config
Personalisation token resolution (no raw tokens visible)
All hyperlinks live and tracking-enabled
Unsubscribe link present and functional
CAN-SPAM / SPAM Act footer present (where applicable)
Content reference ID matches approved brief ID
Send Configuration Checks
Send definition target list/DE matches approved segment
Send date, time, and timezone match brief exactly
Channel matches brief channel specification
Suppression lists in platform match brief-specified lists
Pass Outcome
All checks pass → Approved to Send
Jira comment: full checklist pass report with content ID, audience, send time, link count, personalisation status
Issue transitioned to Approved to Send
Slack notification to campaign manager
Full QA report emailed to campaign owner
Fail Outcome, Send Blocked
Any check fails → QA Failed, Rework Required
Jira comment: each failing check listed with what was found and what must be corrected
Issue transitioned to QA Failed, Rework Required
URGENT Slack to campaign manager: SEND BLOCKED with issue count
QA failure report emailed to campaign owner

API failure (unable to retrieve live content) auto-triggers a fail with escalation note. The campaign cannot proceed without validated content.

Review Validation Logic

The 12-field brief criteria and 16-point pre-send checklist can be customised to match your specific brief schema and regulatory obligations.

Book Strategic Review
Workflow Flow Map

How data and decisionsmove through the architecture

Each workflow follows an identical structural pattern: Jira webhook trigger → status filter → AI agent with tool access → dual output path (success / error recovery). This consistency makes the system predictable, auditable, and maintainable.

Workflow Structural Pattern, Applied Identically Across All Three Gates
JIRA TRIGGER Webhook Event Issue Updated STATUS FILTER IF node status = target AI AGENT Claude Sonnet 4 Reads Jira context Calls tools · decides ✓ PASS PATH Comment → Transition → Slack notify ✕ FAIL PATH Failure report → Block → Alert requester Response output Error recovery Jira webhook Status check Agent + tools Autonomous actions
G1
Gate 1, Node Map
7 nodes · 6 connections
NodeTypeFunction
Jira TriggerjiraTriggerWebhook, fires on any Jira issue update
Status Filterif (v2.2)Passes only if status = "Brief Submitted"
Brief Validation Agentlangchain.agentClaude Sonnet · 12-field validation logic
Add Jira CommentjiraToolPosts validation result to issue
Transition Jira IssuejiraToolMoves to pass or fail status
Slack Notify TeamslackToolAlerts builder or requester
Response / Errorset (x2)Output + error recovery nodes
G3
Gate 3, Node Map (most complex)
11 nodes · 8 connections
NodeTypeFunction
Jira TriggerjiraTriggerWebhook, fires on any issue update
Status Filterif (v2.2)Passes only if status = "QA Approved"
Pre-Send QA Agentlangchain.agentClaude Sonnet · 16-point validation
SFMC Content APItoolHttpRequestRetrieves live email content asset
SFMC Send DefinitiontoolHttpRequestRetrieves send config and audience
Add Jira CommentjiraToolPosts full QA report to issue
Transition Jira IssuejiraToolApproves or blocks campaign
Slack AlertslackToolUrgent alert on fail, confirmation on pass
Send QA EmailgmailToolFull report to campaign owner
Transformation State

The before and afterof campaign operations

This architecture does not change how your team works. It changes the structural conditions under which errors can propagate, by converting human-dependent judgment points into machine-verified checkpoints.

Current State, Before
Campaign briefs enter the build pipeline with ambiguous segment criteria, builder interprets subjectively
75-point manual checklist is the primary QA mechanism, applied under time pressure by humans reviewing already-built campaigns
Audience count validation is a visual check, no API verification of actual segment size vs expected range
Errors discovered post-send, by customers, stakeholders, or compliance teams after delivery
Error resolution requires rework cycles, customer compensation events, delayed re-execution
Regulated categories trigger compliance reporting obligations on every discovered error
QA quality is operator-dependent, inconsistent across team members and workload conditions
30% of campaigns contain errors reaching customers, the baseline that defines the business problem
Target State, After
Gate 1 validates every brief before any builder sees it, ambiguous briefs are returned with specific correction instructions before they consume build capacity
Human QA operates on pre-validated builds, reviewers confirm quality rather than discovering structural errors
Gate 2 makes live API calls to SFMC and SAS, actual audience count verified against brief-declared range before QA begins
Gate 3 validates the live build against approved brief, errors discovered and corrected before send, not after
Campaigns that reach send are structurally validated, rework cycles limited to genuine edge cases
Compliance checks embedded in Gate 3, unsubscribe links, opt-in basis, and regulatory flags verified automatically
Validation quality is consistent, same standards applied to every campaign, regardless of operator or volume pressure
Target state: <5% error rate within 90 days, a structural improvement, not an incremental QA enhancement
30% → <5%
Error Rate Reduction
From chronic post-send discovery to structural prevention
0 hrs
Additional Human Review Time
Validation is automated, no additional headcount required
~3 min
Per-Campaign Validation Time
All three gates execute automatically within minutes of status change
100%
Consistency Rate
Same validation standard applied to every campaign, every time

Evaluate Workflow Integration

Understand how this architecture maps to your current Jira project structure, status workflow, and team operating model.

Evaluate Workflow Integration
Stakeholder Impact

Who this affectsand how their working experience changes

Every role in the campaign operations chain is impacted, but in most cases, the change is invisible from a workflow perspective. The intelligence is embedded; the team simply operates in a validated environment.

Role Current Pain Points Change After Deployment Manual Work Removed Impact
Brief Requester
Marketing / Channel Owner
Discovers errors post-send; unclear what information a brief needs; late feedback on missing fields Immediate, specific feedback if brief is incomplete. Knows exactly what is needed before work begins. Back-and-forth with builders on missing information High Positive
Campaign Builder
Ops / Technology
Receives ambiguous briefs; builds against unclear criteria; rework cycles after errors surface Only receives briefs that have passed Gate 1. Builds against validated, unambiguous specifications. Interpreting vague briefs; rework after post-send errors High Positive
QA Reviewer
Campaign Operations
Reviews against a 75-point checklist; often reviewing flawed builds; high cognitive load under volume pressure Reviews builds that have passed segment validation. Gate 3 handles mechanical pre-send checks. Human QA is elevated, judgment on quality, not mechanical verification. Mechanical checklist execution; audience count verification High Positive
Campaign Manager
Marketing Leadership
Escalation point for post-send errors; customer compensation approvals; compliance reporting Receives Slack alerts at Gate 3 for both pass and urgent fail. Full QA reports emailed automatically. Early visibility, not post-send surprises. Post-send error escalation handling High Positive
Compliance / Risk
Legal / RegOps
Reactive, informed of errors after send; compliance reporting obligations triggered by post-send discovery Gate 1 validates regulatory flags on brief submission. Gate 3 validates unsubscribe links, opt-in basis, compliance footers. Structural compliance enforcement. Post-send compliance incident management Risk Reduction
Head of Campaign Team
Operations Leadership
30% error rate persists despite QA investment; escalations; team credibility; reporting obligations Structural error rate improvement without additional headcount. Audit trail in Jira for every validation decision. Demonstrable quality infrastructure. Error escalation management; team performance conversations Strategic

Explore Department Impact Mapping

A detailed stakeholder impact assessment can be produced for your specific org structure before deployment begins.

Request Impact Assessment
Systems Architecture

Platform relationshipsand data movement

This architecture sits between your existing platforms as an intelligence orchestration layer. It reads from them, validates against them, and writes back decisions, without requiring changes to any platform configuration.

JR
Jira Software Cloud
Central orchestration hub. Campaign briefs live here. Status transitions trigger all three gates. Validation results written back as comments and status changes.
Trigger source Read Write
N8
n8n (Automation Engine)
Workflow orchestration platform. Receives Jira webhooks, routes to AI agents, manages tool connections, handles error recovery. Self-hosted or cloud.
Orchestration layer Error handling
AI
Claude Sonnet 4 (Anthropic)
AI reasoning engine powering all three agents. Reads context, applies validation rules, writes structured outputs. Context window handles full Jira issue data.
Decision engine Natural language
MC
Salesforce Marketing Cloud
Gate 2 queries Data Extension row counts. Gate 3 retrieves Content Builder assets and Email Send Definitions. Read-only API access via OAuth2.
Read (Gate 2+3) OAuth2
SAS
SAS Marketing Automation
Gate 2 queries the Campaign Communications audienceCount endpoint. Returns actual segment size for validation against brief-declared range.
Read (Gate 2) REST API
SL
Slack
Human notification layer. Each gate sends targeted Slack alerts to the relevant team member, builder, QA, or campaign manager, on both pass and fail outcomes.
Write (all gates) Notifications
GM
Gmail / Google Workspace
Gate 3 emails the full QA report to the campaign owner on both pass and fail outcomes. Provides an auditable paper trail outside of Jira.
Write (Gate 3) Audit trail
AN
Future: Analytics Layer
Gate validation data written to Jira creates a structured audit log. Future phase: export to BigQuery or Looker for error pattern analytics and validation performance reporting.
Phase 2
CH
Future: Additional Channels
Gate 2 API pattern is extensible. Additional marketing platforms (Braze, Adobe Campaign, Klaviyo) can be connected as new HTTP tool nodes without rebuilding the core architecture.
Extensible
Data Flow, What moves, where, and in what direction
Data TypeFromToUsed ForGate
Jira issue payloadJira webhookn8n → AI AgentContext for all validation decisionsAll
Brief field valuesJira custom fieldsAI Agent working memoryValidation source of truthG1, G2, G3
Validation decisionAI Agent outputJira CommentAudit trail and team communicationAll
Status transition commandAI AgentJira API (Transition)Pipeline progression or blockageAll
SFMC audience countSFMC REST APIAI AgentSegment size validationG2
SAS audience countSAS APIAI AgentSegment size validation (SAS campaigns)G2
SFMC content assetSFMC Content Builder APIAI AgentSubject, tokens, links, content ID checkG3
SFMC send definitionSFMC Send Definition APIAI AgentAudience, timing, suppression checkG3
QA reportAI Agent outputGmail → Campaign OwnerAudit trail, ownership confirmationG3
Slack alertAI AgentSlack channelHuman notification, escalation triggerAll

Review Operational Architecture

A technical architecture review can validate the integration approach against your specific platform versions, API permissions, and data governance requirements.

Review Operational Architecture
Business Outcomes

Translating automation into commercial value

The metrics that matter to leadership are not technical, they are operational, financial, and reputational. Here is how the architecture translates into the measures that appear in executive reporting.

83%
Error Rate Reduction
30% → <5%. Structural, not incremental, errors prevented upstream rather than caught downstream
Cost
Rework Cost Elimination
Each prevented error eliminates a rework cycle, a customer compensation event, and potential compliance reporting cost
Cap.
Team Capacity Freed
Brief clarification loops, audience count verification, and mechanical pre-send checking removed from human workload
90days
Time to Full Impact
From deployment to target error rate, no multi-year transformation timeline
Operational Value
Campaign error rate 30% → <5%
Brief clarification cycles Eliminated upstream
Audience count validation Machine-verified, always
QA consistency 100% standard application
Post-send discovery Structurally minimised
Strategic Value
Compliance exposure Reduced at source
Scalability Volume-independent quality
Audit trail Every decision documented in Jira
Team capability Human focus on judgment work
Headcount requirement No additional QA resource needed
The compounding return on prevention

Each prevented error eliminates a chain of downstream costs: the rework labour, the delayed campaign window, the customer compensation event, the stakeholder escalation, the compliance reporting obligation if applicable, and the reputational impact on the team's credibility with the broader business. At 100–200 campaigns per month with a 30% error rate, the operational drag from this chain is substantial, and it compounds with volume. This architecture removes that compounding drag at its structural origin.

Schedule Transformation Consultation Request Infrastructure Audit
Implementation Roadmap

From download tooperational quality gates

This architecture is deployable without infrastructure changes, platform migrations, or team training. The implementation sequence below takes you from credential setup to live gate activation in a structured, low-risk progression.

1
Infrastructure Setup
Configure n8n instance and establish all credential connections. This is the foundation, all subsequent steps depend on stable credential configuration.
n8n v1.40+ Anthropic API Key Jira Admin Token Slack OAuth2 Gmail OAuth2 SFMC OAuth2
2
Jira Pipeline Configuration
Map or create the required Jira statuses. Verify the IF node status name values in each workflow match your exact Jira status names. Configure Jira webhooks pointing to n8n URLs.
Status mapping IF node update 3 × Jira webhooks
3
Brief Field Mapping
This is the highest-value configuration step. Map your existing Jira custom field IDs to the field names in Gate 1's validation criteria. Your briefs are already well-structured, this is a straightforward mapping exercise.
Retrieve field IDs via Jira API Map 12 fields to custom field names Update Gate 1 system prompt
4
SFMC API Configuration
Configure SFMC OAuth2 token generation and set your MID subdomain in Gate 2 and Gate 3 HTTP tool node parameters.
Installed Package setup Subdomain placeholder update API permission verification
5
Gate-by-Gate Testing
Test each gate sequentially with controlled test cases, incomplete brief, out-of-range count, content ID mismatch. Verify pass and fail paths operate as expected before production activation.
Gate 1 fail test Gate 1 pass test Gate 2 anomaly test Gate 3 block test Gate 3 approve test
6
Production Activation
Activate all three workflows in n8n. Communicate to the team that the validation layer is live. Monitor the first week of executions in n8n execution logs.
Activate workflows Team communication First-week monitoring
Implementation Checklist
  • Download all 3 workflow JSON files and setup guide
  • Provision n8n instance (v1.40+)
  • Configure Anthropic API credential in n8n
  • Configure Jira Software Cloud credential
  • Configure Slack OAuth2 credential
  • Configure Gmail OAuth2 credential
  • Import all 3 workflow JSON files into n8n
  • Verify/create required Jira statuses (9 statuses)
  • Update IF node status values to match your Jira statuses
  • Configure SFMC Installed Package (Client ID + Secret)
  • Set SFMC subdomain placeholder in Gate 2 + Gate 3
  • Map Jira custom field IDs to Gate 1 validation criteria
  • Activate all 3 workflows + copy webhook URLs
  • Configure 3 Jira webhooks (one per workflow)
  • Configure Slack channel routing in each workflow
  • Run Gate 1 test, fail case (incomplete brief)
  • Run Gate 1 test, pass case (complete brief)
  • Run Gate 2 test, count anomaly case
  • Run Gate 3 test, send block case
  • Communicate activation to campaign team
Progress 0 / 20
Maintenance Cadence
Weekly: Review n8n execution logs for unexpected errors or API failures
Monthly: Review Gate 1 failure patterns, common missing fields indicate brief template improvement opportunities
Quarterly: Update validation criteria as brief schema, platform versions, or regulatory requirements evolve
As needed: Update SFMC subdomain or credential if platform configuration changes

Schedule Transformation Consultation

A guided implementation session can take you from credential setup to live gate activation in a structured half-day engagement.

Schedule Transformation Consultation
Configuration Assets

Ready-to-useconfiguration references

Key configuration references from the generated workflow package. These are production-ready, the validation criteria, API endpoint patterns, and Jira status mappings used directly in the workflow JSON files.

Required Jira Status Workflow
JSON Jira Pipeline Status Map
// Required Jira statuses, create these in your Jira project
// Project Settings → Workflows → Edit → Add Status

"pipeline_statuses": [
  { "name": "Brief Submitted",             "triggers": "Gate 1" },
  { "name": "Brief Required",              "type": "Gate 1 fail destination" },
  { "name": "Ready for Build",             "type": "Gate 1 pass destination" },
  { "name": "Build Complete",              "triggers": "Gate 2" },
  { "name": "Build Required",              "type": "Gate 2 fail destination" },
  { "name": "Ready for QA",               "type": "Gate 2 pass destination" },
  { "name": "QA Approved",                "triggers": "Gate 3" },
  { "name": "QA Failed, Rework Required", "type": "Gate 3 fail destination" },
  { "name": "Approved to Send",           "type": "Gate 3 pass destination" }
]
SFMC API Endpoints, Gate 2 & Gate 3
REST SFMC API Reference
// Gate 2, Audience Count (Data Extension)
GET https://{sfmcSubdomain}.rest.marketingcloudapis.com/data/v1/customobjectdata/key/{dataExtensionKey}/rowset?$pageSize=1

// Gate 2, SAS Campaign Audience Count
GET https://{sasHost}/SASCampaign/rest/v1/campaigns/{campaignId}/communications/{communicationId}/audienceCount

// Gate 3, Content Asset Validation
GET https://{sfmcSubdomain}.rest.marketingcloudapis.com/asset/v1/content/assets/{assetId}

// Gate 3, Send Definition Check
GET https://{sfmcSubdomain}.rest.marketingcloudapis.com/email/v1/definitions/{sendDefinitionId}

// SFMC OAuth2 Token (run before API calls)
POST https://{sfmcSubdomain}.auth.marketingcloudapis.com/v2/token
Body: { "grant_type": "client_credentials", "client_id": "{clientId}", "client_secret": "{clientSecret}" }
Gate 1, Validation Failure Comment Template
Jira comment structure produced on brief validation failure, shows exactly the format your team will see
Jira Comment Brief Failure Report Format
BRIEF VALIDATION FAILED, 2024-03-15 09:42 AEST

3 fields require correction before build can begin:

Target Segment Criteria:
Found: "active customers who have purchased recently"
Required: Specific, filterable criteria, e.g. "opted-in email subscribers with a purchase in the last 90 days, excluding lapsed segment"

Suppression Groups Required:
Found: "standard suppression"
Required: Named suppression lists, e.g. "Unsubscribes_Master, Complaints_2024, DNC_Financial"

Stakeholder Approval:
Found: "approved by marketing team"
Required: Named approver and approval date, e.g. "Approved by Sarah Chen, 2024-03-14"

Once corrected, change status back to 'Brief Submitted' to re-trigger validation.
Do not ask the build team to start work until this is resolved.
Jira Custom Field Discovery
Use this API call to find all Jira custom field IDs in your instance
REST Find Your Custom Field IDs
// Call this to retrieve all custom field IDs in your Jira instance
// Replace {domain} with your Jira domain (e.g. your-company.atlassian.net)

GET https://{domain}/rest/api/3/field
Authorization: Basic {base64(email:api_token)}
Accept: application/json

// Response, look for entries where "id" starts with "customfield_"
// Map these IDs to your brief field names in the Gate 1 system prompt

{
  "id": "customfield_10001",
  "name": "Expected Audience Min",
  "type": "number"
}
Workflow Package Contents

Four files have been generated and are ready for download and deployment:

workflow-01-brief-validation-gate.json
workflow-02-segment-sanity-check.json
workflow-03-presend-qa-gate.json
campaign-qa-automation-setup-guide.md

Import each JSON file via n8n → Workflows → Import. Follow the setup guide for the complete credential and configuration sequence.

Begin Implementation

All workflow files are ready. The setup guide walks through every configuration step. A guided deployment session is available if preferred.

Schedule Transformation Consultation